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RESUMO 


Este artigo objetiva o estudo e o desenvolvimento com a linguagem C++ de firmware para 
microcontroladores ARM Cortex-M através de diagramas e códigos de programação, usando as 
famílias STM32 e LPC, além do ambiente IAR Embedded Workbench. No trabalho, são 
apresentados os elementos essenciais de um projeto modular de firmware em baixo nível, além de 
aplicações em código de design patterns voltados à otimização de recursos em sistemas eletrônicos. 
Em particular, é abordada a linguagem C++ e a orientação a objetos atualmente empregadas na 
família ARM Cortex-M, em comparação com a tradicional linguagem C de desenvolvimento. Com o 
foco na compactação do C++, demonstra-se com exemplos pontos positivos e negativos da prática 
do alto nível em microcontroladores atuais de 32 bits. Os resultados mostram que a programação 
disciplinada do C++ possibilita a criação e a manutenção facilitada do firmware de 
microcontroladores, instigando os meios industrial e científico na melhora contínua de seus padrões. 


PALAVRAS-CHAVE: Linguagem C++. Microcontroladores ARM Cortex-M. Recursos. 


ABSTRACT 


This article aims to the study and the development with the language C++ of firmware for 
microcontrollers ARM Cortex-M throught programming diagrams and codes, using the STM32 and 
LPC families, besides the environment IAR Embedded Workbench. In the work, it is presented the 
set of essential elements for a modular project of low-level firmware, besides coding applications of 
design patterns directed to the optimization of resources in electronic systems. In particular, the C++ 
language and its object orientation currently applied within the ARM Cortex-M are addressed, 
comparatively to the conventional C language of development. Focused on the C++ reduction, it is 
demonstrated by examples a group of positive and negative characteristics of the high-level pratice 
with modern 32-bit microcontrollers. The achieved results show that the disciplined C++ 
programming makes it possible to create and to maintain microcontroller firmware in an easier way, 
stimulating the industrial and cientific fields in the continous improvement of their standards. 


KEYWORDS: Language C++. Microcontrollers ARM Cortex-M. Resources. 


1 INTRODUÇÃO 


Um microcontrolador é um sistema microprocessado de chip único que contém memórias de 
dados e de programa, entradas e saídas do tipo série e paralela, interrupções internas e externas, 
entre outros, com todos esses os recursos armazenados em circuito integrado. Produtos eletrônicos 
em geral, como máquinas militares, médicas e de escritório, são fabricados com essa tecnologia. 
Tradicionalmente, os microcontroladores eram programados com as linguagens de montagem, ou 
Assembly, de suas respectivas arquiteturas de instruções, com tais linguagens consistindo de curtas 


2 


descrições mnemônicas. Pela complexidade da produtividade com o Assembly, surgiu o alto nível 
de abstração, em contraponto ao baixo nível de programação, e linguagens que o definiam, como o 
BASIC e o C. Com essa inovação, projetos de firmware em microcontroladores tornaram-se mais 
legíveis, portáveis e modificáveis, melhorando as manutenções de código. [1] 

Em meados do século XX, a linguagem de programação C teve destaque por sua popularidade 
no desenvolvimento comercial e industrial de software. Caracterizava-se, sobretudo, pelo paradigma 
da programação estruturada, sendo ações repetitivas tratadas por procedimentos e dados 
complexos tratados por estruturas. Unindo tais conceitos em classes e objetos, controlando então 
informação e fluxo de programa da mesma forma, surgiu no final do século XX e começo do século 
XXI a linguagem de programação C++, influenciada por linguagens da época, como Smalltalk. Com 
o crescimento da complexidade global do software, a orientação a objetos e sua abstração em alto 
nível tornaram dominante a linguagem C++ de programação, criada para esse fim, além de outras 
como Java. [2] [3] 

Na área dos sistemas eletrônicos com microcontroladores, a transição de C para C++, e 
consequentemente para a orientação a objetos, foi dificultada pela escassez de recursos de 
programação, como memória e velocidade de processamento. Atualmente, ainda é comum o 
favorecimento das linguagens Assembly e C nesse campo, acompanhado do pensamento de que o 
C++ demanda recursos e complexidade em excesso. [4] 

O surgimento no mercado internacional de muitos e diversos microcontroladores de 32 bits com 
significativamente mais memória e velocidade, contudo, permitiu a ingressão de novas técnicas de 
código antes inviáveis. [5] Com relação às linguagens de baixo nível convencionais, seria possível 
aplicar satisfatoriamente a linguagem sucessora C++ em alto nível, na produção de firmware 
embarcado, usando a moderna família ARM Cortex-M? 

A escolha de uma linguagem de programação e de seus paradigmas com frequência afeta 
profundamente os projetos de firmware, de modo que a pesquisa nesse campo faz-se necessária 
quando há possibilidades teóricas de alternativas para o desenvolvimento prático. Em sentido 
específico, é importante melhorar a organização e o controle do processo produtivo do firmware 
embarcado, para que este possa adaptar-se, em conjunto, com o hardware eletrônico, conforme 
este também sofre atualizações no decorrer do tempo. 

O objetivo geral deste trabalho científico é contribuir para o estudo e para o desenvolvimento 
das tecnologias da informação, no caso aplicadas ao desenvolvimento de software, em particular 
na produção de firmware eletrônico. Pretende-se viabilizar, em termos de utilização em projetos, o 
desenvolvimento de aplicativos em C++ para microcontroladores modernos do tipo ARM Cortex-M, 
como os das séries STM32 da STMicroelectronics e LPC da NXP Semiconductors, incluindo o uso 
do IDE atualizado IAR Embedded Workbench. Como objetivos específicos, tem-se: explicar as 
variadas técnicas de organização e otimização, em se tratando de projetos de firmware embarcado; 
descrever os microcontroladores de 32 bits da família ARM Cortex-M, sobretudo na capacidade de 
suportar programação em alto nível; apresentar os design patterns em C++ cabíveis a sistemas 
críticos, com ênfase na redução da linguagem para microcontroladores; mostrar o desenvolvimento 
em C++ comparativamente ao na linguagem C, expressando, através de exemplos em código, 
vantagens e desvantagens. 


2 CONCEITOS DE FIRMWARE EM MICROCONTROLADORES 


Nas últimas décadas, os sistemas embarcados vêm crescido em complexidade. Os sistemas 
que antes eram simples e autônomos atualmente têm que se conectar via internet de forma segura 
e livre de falhas, assim transferindo informações pela nuvem. Técnicas arcaicas não-reutilizáveis e 
de difícil portabilidade empregadas em 1980 estão sendo superadas no âmbito do firmware, focando 
no ganho em certas qualidades: ser modular; ser fracamente acoplado; ter coesão entre partes; 
aplicar encapsulamento e tipos de dados abstratos; entre outros, como ser bem documentado e ser 
escrito de acordo com convenções adotadas para a linguagem de programação usada. [6] 

A separação de um projeto de firmware em módulos interconectados traz o benefício primário 
de quebrar uma estrutura complexa de funcionalidades em pequenos arquivos de propósito único, 
melhorando a organização e, conforme o paradigma procedural, a otimização dos códigos. Contudo, 
o sucesso dessa técnica depende do empenho em certas práticas, como a da escrita de módulos 
fracamente acoplados, ou seja, tão independentes quanto possível, conforme a Figura 1. [6] 


(b) 


Fig. 1 — Em a) e b), módulos forte e fracamente acoplados, respectivamente. [6] 


Juntamente com a divisão em arquivos módulos, um projeto de firmware, mesmo em baixo nível 
e com recursos computacionais limitados, deve seguir um padrão arquitetural de software. Conforme 
a engenharia de software, a especificação de uma arquitetura que separe em conjuntos majoritários 
um projeto de firmware garante melhores controle e manutenção do sistema. É típico aplicar, para 
projetos com microcontroladores em geral, a layered architecture ou arquitetura em camadas, com 
uma camada para drivers — interfaces de periféricos —, outra camada para middleware — módulos 
básicos para as aplicações — etc, o que é ilustrado na Figura 2. [6] 
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Fig. 2 — Arquitetura com quatro camadas, típica de microcontroladores. [6] 


Para seguir uma determinada arquitetura de firmware, os códigos correspondentes devem ser 
escritos com a noção de encapsulamento, isto é, de abstração de funções complexas a partir das 
funcionalidades fundamentais. Principalmente, então, para resolver problemas de estruturação de 
software, aplicam-se os denominados design patterns ou padrões de projeto, os quais são para o 
desenvolvimento de aplicações um conjunto de soluções empregadas em situações recorrentes. [7] 

O conceito de design pattern está ligado com o paradigma orientado a objetos, já que este foi 
criado para fins de abstração de códigos de software. Isso, porém, não limita sua aplicação a 
linguagens orientadas a objetos, como o C++, uma vez que a perspectiva orientada a objetos é 
também identificada no C, por exemplo, uma linguagem estruturada, apesar da falta de sintaxe 
dedicada. [7] Verifica-se, assim, que um design pattern é um bloco de alto nível na construção de 
um software, e não exatamente um código de programação. [8] 

Todo padrão de projeto inclui, por definição, um nome para sua referência, um propósito o qual 
é o problema a ser resolvido, uma solução que é o próprio design pattern, e por fim consequências, 
que não só são analisadas isoladamente para as situações particulares, mas também abrangendo 
o conjunto das interações entre os padrões que constituem o projeto de software. [7] [8] 

Graficamente, a engenharia de software representa um design pattern através de convenções 
denominadas linguagens de modelagem, como o UML e o SysML. Tais expressões evidenciam, em 
detalhes, os padrões em que os códigos de programação são organizados. A Figura 3 ilustra o 
design pattern genérico Facade implementado para fins de ocultação de complexidade, no caso, 
para códigos de manipulação de arquivos. [9] 
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Fig. 3 —- Um diagrama de modelagem UML para o padrão Facade. [9] 


Em se tratando de firmware para microcontroladores e sistemas embarcados em geral, existem 
design patterns específicos, normalmente escritos em C, os quais são próprios desse ambiente de 
programação próximo do hardware, tanto para aplicações bare-metal — sem sistema operacional — 
quanto para outras mais complexas. Entre esses padrões, os enumerados a seguir são os mais 
fundamentais, visto que compõem a base de uma arquitetura de camadas tradicional, sobretudo os 
setores de hardware — também denominado hardware abstraction layer — e de drivers. [7] 


e Hardware Proxy Pattern: encapsula o hardware por uma classe; 

e Hardware Adapter Pattern: adapta uma interface requerida para uma fornecida; 
e Mediator Pattern: coordena interações complexas entre partes; 

e Observer Pattern: auxilia na distribuição eficiente de dados de sensores; 

e Debouncing Pattern: rejeita sinais de hardware intermitentes; 

e | Interrupt Pattern: gerencia sinais de hardware de urgência — prioridade —; 


e Polling Pattern: periodicamente checa por novos dados de sensores. [7] 


Além dessas técnicas, extensivamente usadas na programação de microcontroladores, há ainda 
modelagens relativas à manutenção de concorrência e de recursos de processamento, que são com 
frequência presentes em aplicações de tempo real, sobretudo quando várias tarefas são controladas 
por um RTOS ou sistema operacional em tempo real. Entre estes, o Cyclic Executive Pattern, o mais 
simples para escalonamento de prioridades, e o Static Priority Pattern, característico do RTOS. [7] 

Sobretudo para abordagens bare-metal, há também design patterns direcionados ao paradigma 
de programação orientado a máquinas de estados finitos. Nestes padrões, as máquinas de estados 
são exploradas, enquanto modelos para sistemas digitais, para a abstração do comportamento de 
diversas funções desempenhadas pelo firmware de microcontroladores. O State Pattem, técnica 
tradicional na linguagem C++, é um padrão baseado nas máquinas de estados finitos, podendo, 
com o devido controle de recursos consumidos, ser aplicado em microcontroladores. [7] [8] 

Normalmente, em um projeto com microcontroladores, o processador é apenas um subsistema, 
havendo muitos outros incluindo unidades de memória — ambas voláteis e não-voláteis —, interfaces 


analógicas e digitais para entrada e saída, periféricos de comunicação etc. Muitos fabricantes de 
microcontroladores têm adotado os processadores ARM Cortex-M como CPU, mas, apesar disso, 
ocorrem muitas variações entre blocos integrados de fabricante para fabricante. Como resultado, 
um microcontrolador ARM Cortex-M possui capacidades totalmente distintas de outro de mesma 
arquitetura pertencente a um fabricante diferente, conforme a Figura 4. Devido à essa flexibilidade, 
diferentes circuitos integrados com o núcleo do tipo ARM Cortex-M surgem, conforme mercados 
específicos vão sendo explorados. [10] 
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Fig. 4 — Diagrama da arquitetura ARM Cortex-M para os tipos Cortex-M3/M4. [10] 


A linha ARM Cortex-M é focada em particular para aplicações com microcontroladores. Nesta 
família, encontram-se os denominados núcleos ARM Cortex-MO, MO+, M1, M3 e M4. Trata-se de 
uma arquitetura de 32 bits do tipo RISC, que, à medida que o espaço dos microcontroladores de 8 
bits é substituído por novos microcontroladores de 32 bits, apresenta características de baixo custo, 
programação rápida e baixo consumo de potência elétrica. [10] [11] 

Outrossim, o nível tecnológico da fabricação do ARM Cortex-M permite aos microcontroladores 
características robustas em termos de recursos computacionais. A título de exemplificação, tem-se 
o LPC1768, um microcontrolador do tipo ARM Cortex-M3 da NXP Semiconductors, o qual constitui 
uma das plataformas de desenvolvimento mais utilizadas. O mesmo é capaz de executar firmware 
na velocidade de 96 MHz, contendo 32 kB de SRAM — memória de dados — e 512 kB de memória 
FLASH — memória de programa —, incluindo ainda interfaces integradas como: I2C, SPI, CAN, USB, 
ADC, DAC, PWM, entre outras. [12] 

Em termos de programação de firmware, os microcontroladores ARM Cortex-M são escritos em 
Assembly como linguagem básica, podendo operar com somente um subconjunto das instruções 
disponíveis na família ARM, além de possuírem modelos de memória relativamente simples. Em 
especial, os tipos ARM Cortex-M3 e ARM Cortex-M4, mais antigos e com maiores capacidades, são 
direcionados a altas densidades de código, rápidos tempos de resposta a interrupções, entre outros, 
similarmente aos microcontroladores de 8 bits dos anos 1970 e 1980. [11] 

Quanto às linguagens C e C++ no ambiente ARM Cortex-M, ambas são possíveis através dos 
conjuntos de compiladores dedicados à plataforma, entre eles o GNU ARM GCC, o Keil ARMCC 
Compiler e o IAR ARM Compiler. Nestes, ambas as linguagens divergem pouco do padrão, cabendo 
aos usuários a compensação entre os recursos e os conteúdos utilizados das mesmas. Apesar da 
linguagem C ser muito aplicada no ARM Cortex-M, percebe-se a presença significativa do C++ em 
projetos complexos, como o sistema operacional mbed cuja linguagem principal é o C++. [12] 


3 DESENVOLVIMENTO EM C++ PARA ARM CORTEX-M 


Um projeto de firmware tem no começo de seu desenvolvimento a definição de uma arquitetura 
básica de software. Nesta, são especificados quais módulos fazem parte da totalidade do sistema, 
além das dependências entre os mesmos. Então, os códigos de programação, os design patterns e 
os algoritmos em geral passam a receber a atenção em trabalhos posteriores no firmware. Para 
estudar a programação de microcontroladores com a linguagem C++, em princípio, foi escolhido o 
circuito integrado STM32F072RB da STMicroelectronics, do tipo ARM Cortex-MO, o qual contém 
128 kB de memória FLASH, 16 kB de memória SRAM e 48 MHz de velocidade de processamento. 
O ambiente de desenvolvimento usado foi o IAR Embedded Workbench for ARM, na versão 8.3. 

Primeiramente, deve-se identificar quais técnicas específicas do C++ são viáveis no chip ARM 
Cortex-MO em questão. Verifica-se que keywords da linguagem C++ pura, além das oriundas do C, 
são em grande parte seguras, como: class, public, private e protected para criação de classes e 
objetos em C++; static cast, const cast, dynamic caste reinterpret cast para mudanças entre tipos 
de dados; operator e virtual para sobrecarga de operadores e funções, respectivamente; entre 
outras de caráter complexo e características do C++, como namespace e template. [13] 

Contudo, algumas keywords da linguagem C++ contêm recursos que podem ser limitantes, 
como new e delete, uma vez que ocasionalmente vão de encontro aos requisitos de um sistema 
embarcado baseado em microcontrolador. Por exemplo, no caso dos recursos referidos, sabe-se 
que a alocação dinâmica em microcontroladores apresenta riscos de fragmentação de memória 
SRAM e dificuldades na estimativa do consumo de memória durante o processo de compilação. [14] 
Além dos termos reservados, o que inclui construções de controle de fluxo como switch e while, a 
sintaxe e os operadores do C++ são disponíveis e cabíveis, o que traz a escrita idiomática de 
códigos particulares do C++ para os sistemas de firmware eletrônico, conforme a Figura 5. [13] 


template<typename port type, 
typename bval type, 
const port type port, 
const bval type bval> 
class led template 
t 
public: 
led template() 
( 
// Set the port pin value to low. 
*reinterpret cast<volatile bval typex+> (port) 
& static cast<bval type>(-bval); 


// Set the port pin direction to output. 
*reinterpret cast<volatile bval type+>(pdir) 
|= bval; 
) 


static void toggle() 


( 


// Toggle the LED. 
*reinterpret cast<volatile bval type+x>(port) 
*= bval; 
) 


private: 
static constexpr port type pdir = port - 1U; 


); 


Fig. 5 — Classe em C++ de controle GPIO para LED, em firmware. [13] 


Tomando como base uma modelagem de firmware simplificada, pode-se escrever um driver de 
barramento digital SPI para comunicação serial via polling, isto é, com interações externas síncronas 
em relação a outros códigos — passíveis de aplicação do Polling Pattern —, não assíncronas como 
interrupções — de uso do Interrupt Pattern —. Como o pacote STM32Cube, para microcontroladores 
STM32, fornece uma camada de hardware ou HAL padrão para a escrita de tais interfaces, pode- 
se escrever um código básico em C que foque na organização e aspectos abstratos do módulo de 
driver em si, como mostrado na Figura 6. [15] 


[9] Project - IAR Embedded Workbench IDE - Arm 8.30.1 
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45 21 HandleTypeDer SpiHandle; 
46 uintê t aTxBuffer[] = "SPI Communication - Polling”; 
47 uintê t aRxBuffer [BUFFERSIZE]; 


49 [-] void spi config bus (void) ( 

50 | SpiHandle.Instance = SPIx; 

51 | Spilandle.Init.BaudRatePrescaler = SPI BAUDRATEPRESCALER 256; 
52 Spifiandle.Init.Direction = SPI DIRECTION 2LINES; 

53 Spifiandle. Init.CLKPhase = SPI PHASE 1EDGE; 

54 Spifiandle.Init.CLKPolarity = SPI POLARITY LOW; 

ss Spifiandle.Init.CRCCalculation = SPI CRCCALCULATION DISABLE; 
56 SpiHandle.Init.CRCPolynomial = 7; 

57 Spifiandle.Init.DataSize = SPI DATASIZE 8BII; 

58 Spifiandle.Init.FirstBit = SPI FIRSIBIT MSB; 

59 Spifiandle.Init.NSS = SPI NSS SOFT; 

co Spifiandle.Init.TIMode = SPI TIMODE DISABLE; 

61 SpiHandle.Init.NSSPMode = SPI NSS PULSE DISABLE; 

62 SpiHandle.Init.CRCLength = SPI CRC LENGIH &BII; 

63 Spifiandle.Init.Mode = SPI MODE SLAVE; 

64 ) 

65 [] HAL StatusTypeDef spi init sys(void) f 

66 | return HAL SPI Init(s«SpiHandle); 

ql) 

68 [] HAL StatusTypeDef spi run check(void) ( 

69 | retum HAL SPI TransmitReceive (sSpifandle, (uintê t*) aTxBuffer, (uintê t *) aRxBuffer, BUFFERSIZE, TIMEOUI); 
7 LL) 


Fig. 6 — Simples driver de SPI em C com base na HAL padrão do STM32. [15] 


Verifica-se que as variáveis globais, que se tornam locais restritas quando o arquivo do driver é 
posicionado na hierarquia do firmware, são características da linguagem C. A tentativa de contornar 
isso com passagens por parâmetros aumentaria a complexidade individual das funções. Ainda, em 
certas ocasiões, o acoplamento dos módulos seria inconvenientemente fortalecido, como se por 
necessidade uma variável global fosse externada para acesso por outra parte do firmware. [6] 

Ainda, se fosse necessário que o driver em si fosse modificado por módulos que o usassem, ele 
teria que ser reescrito, com novos parâmetros para funções, por exemplo. Se apenas um usuário 
precisasse da alteração retroativa, ela teria que ser feita mesmo que outros usuários — códigos — 
não precisassem. A facilidade de reutilização, além de um controle de escopo aperfeiçoado sobre 
variáveis, constantes e funções, é provida pela orientação a objetos da linguagem C++, conforme é 
ilustrado na Figura 7. 

A versão em C++ do código da Figura 6 realiza o encapsulamento dos métodos, ou funções 
membros, e também dos campos, que eram as variáveis globais presentes no arquivo. Os termos 
public e private do C++ são responsáveis por esse efeito. Outrossim, há a função adicional chamada 
de constructor da classe, que inicializa a classe sempre que uma variável — objeto — é criada para o 
seu conteúdo interno, sendo o destructor similar na destruição do objeto. [16] 

Na prática, a instanciação de objetos para uma classe faz com que ela tenha flexibilidade, por 
exemplo, na passagem de parâmetros, que pode ser feita genericamente para todos os membros, 
como na classe aplicada por template da Figura 5. Com o auxílio do constructor e do destructor, 
ainda, distintas instâncias do mesmo driver podem ser criadas, com independência. Possivelmente, 
em firmware, esses conceitos podem inclusive facilitar a inicialização de hardware, como na reunião 
de funções como spi config bus da Figura 6 nas rotinas de construção de classes. [15] [16] 


[9] Project - IAR Embedded Workbench IDE - Arm 8.30.1 
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84 pass Spi 
est) l 


86 private: 

87 SPI HandleTypeDef SpiHandle; 

ee uintê t aTxBuffer (STRINGSIZE]; 

89 uintê t aRxBuffer [BUFFERSIZE]; 

90 public: 

91 Spi() : SpiHandle(), aTxBuffer("SPI Communication - Polling”), aRxBuffer() Ú 
92 

93 E void config bus (void) f 

94 SpiHandle.Instance = SPIx; 

95 Spifiandle.Init.BaudRatePrescaler = SPI BAUDRATEPRESCALER 256; 
96 SpiHandle.Init.Direction = SPI DIRECTION 2LINES; 

97 Spifiandle.Init.CLKPhase = SPI PHASE 1EDGE; 

se SpiHandle.Init.CLKPolarity = SPI POLARITY LOW; 

99 Spifiandle.Init.CRCCalculation = SPI CRCCALCULATION DISABLE; 
100 SpiHandle.Init.CRCPolynomial = 7; 

101 SpiHandle.Init.DataSize = SPI DATASIZE SBIT; 

102 SpiHandle.Init.FirstBit = SPI FIRSIBII MSB; 

103 SpiHandle.Init.NSS = SPI NSS SOFT; 

104 SpiHandle.Init.TIMode = SPI TIMODE DISABLE; 

105 Spifiandle.Init.NSSPMode = SPI NSS PULSE DISABLE; 

106 Spifiandle.Init.CRCLength = SPI CRC LENGTH SBIT; 

107 Spifiandle.Init.Mode = SPI MODE SLAVE; 

108 | ) 

109 

110 E HAL StatusTypeDef init sys (void) f 

111 return HAL SPI Init (&Spiliandle); 

112 | ) 

113 

114 5] HAL StatusTypeDef run check (void) ( 

115 return HAL SPI TransmitReceive (sSpiHandle, (uintê t*) aTxBuffer, (uintê t *) aRxBuffer, BUFFERSIZE, TIMEOUT); 
116 | ) 

117 L 3; 


Fig. 7 — Driver em C++ de SPI utilizando a HAL padrão do STM32. [15] [16] 


A utilização da linguagem C++ em sistemas embarcados com microcontroladores é aproveitada 
de melhor forma em se tratando dos modelos ARM Cortex-M3 e ARM Cortex-M4, como o LPC1768 
na NXP Semiconductors. Neles, os design patterns tradicionais do C++ os quais aplicam memórias 
dinâmicas são mais apropriados, dadas as capacidades maiores desses microcontroladores. [8] 
Ainda, nos mesmos, os sistemas operacionais em tempo real, como o FreeRTOS, são frequentes, 
o que garante segurança no gerenciamento de memórias dinâmicas. A título de exemplificação, é 
possível efetuar sobrecargas via operator nos operadores new e delete, assim substituindo seus 
comportamentos pelas funções de alocação dinâmica próprias do FreeRTOS. [14] [17] 

Contudo, percebe-se que a linguagem C++ original no ambiente embarcado sofre limitações 
críticas, como a Standard Template Library ou STL, biblioteca padrão exclusiva do C++, que se 
apresenta excessivamente custosa em recursos para a maioria de suas funcionalidades. Por essa 
razão são criadas muitas vezes adaptações leves, como o projeto Embedded Template Library ou 
ETL, que também possui containers estáticos em vez de dinâmicos. [17] [18] 

De acordo com a Figura 8, tem-se um projeto C++ no LPC1768 empregando o design pattern 
clássico Factory, que desempenha o papel de criar classes de controle para que estas envolvam 
subclasses, importantes para o firmware, e gerenciem objetos para elas [8]. Tais subclasses no 
exemplo são Buzzer e Loudspeaker, sendo que cada uma inicializa uma tarefa FreeRTOS. Nesse 
padrão de projeto, a segmentação auxilia na correção de erros no software, no desenvolvimento de 
novas funcionalidades e, por fim, na compreensão de códigos por diferentes profissionais da área. 

Verifica-se que a aplicação de padrões de abstração em C++ é verbosa, resultando em maior 
quantidade de códigos escritos, se comparada à escrita típica da linguagem C. Outros detalhes, 
como a versão do compilador ou da própria linguagem C++, costumam impactar em sua aplicação 
satisfatória no contexto de firmware para microcontroladores. Desde o C++11, são frequentes novos 
artifícios de software, como a substituição de ponteiros normais por smart pointers como shared ptr 
e unique ptr, práticas que podem às vezes ser inapropriadas em firmware. [19] 


[9] FreeRTOS - IAR Embedded Workbench IDE - Arm 8.30.1 

File Edit View Project Simulator Tools Window Help 

DIR & XD Dc «Ss A2$%M=<0>01I) BO=OrM im, 
main x o o E SE 
Sound 


28 iass Sound 


290] [ 

30 public: 

31 virtual void Init(void) = 0; 
32 virtual -Sound (void) Ú 
33 ks: 


35 class Buzzer : public Sound 


360] [ 

37 public: 

38 E] void Init (void) f 

39 xTaskCreate (prvBuzzerTask, "Buzzer”, configMINIMAL STACK SIZE, (void *) NULL, mainBUZZER TASK PRIORITY, NULL); 
40 + ) 


4 LI; 


43 class Loudspeaker : public Sound 


44 [ 

45 public: 

46 E void Init (void) ( 

47 xTaskCreate (prvLoudspeakerTask, "“Loudspeaker”, configMINIMAL STACK SIZE, (void *) NULL, mainLOUDSPEAKER TASK PRIORITY, NULL) ; 


48 | ) 
49 y; 


51 class Factory 


s20] [ 

53 public: 

54 static Sound *Device (const string «param) 

ss E] ! 

56 if(param == "Buzzer”) return new Buzzer(); 

57 if(param == "Loudspeaker”)  retum new Loudspeaker(); 
se return NULL; 


JU) y; 


62 int main (void) 


Sol 

64 Rtos::Start(); 

6s 

66 Sound *buzzer = Factory::Device("Buzzer"); 
6 buzzer->Init (); 

8 Sound *loudspeaker = Factory::Device("Loudspeaker"); 
69 loudspeaker->Init(); 

70 

nm delete buzzer; 

72 delete loudspeaker; 

73 

74 for(;;); 

75 

76 return 0; 


Fig. 8 — Inicialização em C++ e FreeRTOS de dispositivos via Factory Pattern. [19] 


4 CONCLUSÃO 


Através deste estudo, observou-se que existem diferentes tipos de recursos de programação na 
linguagem C++, estes capazes de atuar, de forma seletiva, em firmware com microcontroladores, 
sobretudo no tocante aos termos, expressões e detalhes sintáticos e semânticos inerentes ao idioma 
do C++. Foram tratados em destaque o paradigma e o estilo orientados a objetos do C++ em relação 
ao caráter de programação estruturada pertencente à linguagem C. Implementações de design 
patterns específicos do C++, além de variadas práticas de elaboração de códigos apropriadas, 
receberam abordagens voltadas à plataforma ARM Cortex-M e seus diferentes membros. 

Pelo trabalho realizado, verifica-se que a linguagem C++ por tradição compreende conceitos e 
técnicas de programação voltados à abstração e à organização de um sistema de software, diferente 
das linguagens C e Assembly, em que as interações com o hardware e os recursos como memória 
disponível são primazes. Com controle e restrição aplicados, além de atenção a peculiaridades no 
desenvolvimento do código, o C++ em firmware demonstra uma série de pontos vantajosos os quais 
são bem explorados pelos elevados recursos eletrônicos da família ARM Cortex-M. Conforme as 
intenções no decorrer do projeto, desvantagens associadas ao C++ podem surgir, como precisar da 
inclusão de bibliotecas externas, por exemplo, a Embedded Template Library. 
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Nota-se, contudo, que nos sistemas embarcados baseados em microcontroladores persistem 
as práticas e convenções associadas à linguagem C, uma vez que as relações de custo-benefício 
na produção fabril eletrônica originalmente a favorecem, o que frequentemente afeta a própria 
qualidade dos projetos de software em C. Isso traz a necessidade adicional de, ao aplicar o C++ 
nesse contexto, evitar-se o overengineering em termos de abstração de software, ou seja, de não 
cometer excessos de orientação a objetos e de design patterns de alto nível, se em detrimento dos 
objetivos do projeto de engenharia quanto a memórias de armazenamento, velocidades de clock, 
temperaturas de operação e demais atributos derivados dos circuitos eletrônicos. 

Em última instância, a pesquisa sobre a linguagem C++ em firmware para microcontroladores 
da atualidade, além de seus aspectos e detalhes técnicos, pelos diversos projetos e áreas de 
atuação que podem ser beneficiados por meio dos seus princípios de efetividade em software, 
incentiva os processos de desenvolvimento por parte da sociedade nas áreas comerciais, industriais 
e científicas. Isso por assim se propiciar um maior domínio e compreensão das técnicas de produção 
e dos fenômenos de controle e automação, incluindo as devidas aplicações. 
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